[アップデート]EKS にノードの自動修復機能が追加されました

[アップデート]EKS にノードの自動修復機能が追加されました

EKS にノードの自動修復機能が追加されました。
本機能を有効化することにより、EKS ノードに問題が生じた際に自動でノードを再作成することができます。
合わせて EKS アドオンとしてノード監視エージェント(eks-node-monitoring-agent)が追加され、ノードログから詳細な情報を取得できるようになりました。

https://aws.amazon.com/jp/about-aws/whats-new/2024/12/node-health-monitoring-auto-repair-amazon-eks/

自動修復とノード監視エージェントについて

自動修復を有効にすることで、EKS ノードが Ready であるかどうかを確認して、異常がある場合にノードを更新することができます。
kubectl get node で取得できる、いわゆる各ノードの状態ですね。

% kubectl get node
NAME                                                STATUS   ROLES    AGE    VERSION
ip-192-168-61-169.ap-northeast-1.compute.internal   Ready    <none>   18m    v1.31.3-eks-59bf375
ip-192-168-66-205.ap-northeast-1.compute.internal   Ready    <none>   136m   v1.31.3-eks-59bf375

この情報は kubelet が定期的に情報を送信するものであるため、追加のコンポーネントは不要で利用することができます。
自動修復単体で利用しても良いのですが、ノード監視エージェントをアドオンとして追加することで、ノードのログ情報を取得してより詳細な情報を確認できるようになります(PID の枯渇や、GPU ノードの NVIDIA ドライバ異常など)。
ノード監視エージェントが検知した「より詳細なイベント」に対しても自動修復をキックできるため、自動修復の対象範囲が広がる形になります。

By itself, node auto repair can react to the Ready condition of the kubelet and any node objects that are manually deleted. When paired with the node monitoring agent, node auto repair can react to more conditions that wouldn’t be detected otherwise. These additional conditions include KernelReady, NetworkingReady, and StorageReady.
https://docs.aws.amazon.com/eks/latest/userguide/node-health.html#node-auto-repair

また、ノード監視エージェントをインストールすることで、自動修復はキックしないものの、ノードに対して影響があるイベントを確認できます。
詳しい検知項目はEnable node auto repair and investigate node health issues にまとまっており、Severity が Event のものは検知のみで自動修復なし、Condition のものは自動修復ありのイベントになるようです。

イベントを検知してから自動修復を行うまでに、基本 30 分の猶予を設けるようです。
一部 NVIDIA ドライバー関連のイベントは猶予期間が短く、10 分となります。
既に障害が起きているノードであれば、即座に取り替えて欲しいくらいの気持ちになりそうですが、ノードに異常があってもそのノードに Pod が配置されないだけでシステム全体として落ちるわけではない(落ちないように設計すべき)と考えると、このくらいがちょうど良いのかもしれません。

Amazon EKS waits 10 minutes before acting on the AcceleratedHardwareReady NodeConditions, and 30 minutes for all other conditions.
https://docs.aws.amazon.com/eks/latest/userguide/node-health.html#node-auto-repair

ちなみに、Auto Mode の場合は特に設定しなくても両方の機能が有効になります。

EKS Auto Mode comes with both the node monitoring agent and node auto-repair enabled.
https://aws.amazon.com/jp/about-aws/whats-new/2024/12/node-health-monitoring-auto-repair-amazon-eks/

そもそも Auto Mode では EKS ノードの管理が AWS の責務になっているので、こちらが有効になっていてもいなくてもあまり意識することはないかもしれませんが...

スクリーンショット 2024-12-28 23.54.17.png

(参考)EKS Auto Mode! | AWS RE:INVENT 2024 RECAP IN ZOZO

非 Auto Mode のクラスターを運用している場合は、構成を大きく変えずに運用負荷を下げることができるので、特にメリットが大きそうですね。

やってみた

では実際に試してみます。
非 Auto Mode の EKS クラスターを eksctl で作成します。

apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig

metadata:
  name: test-cluster
  region: ap-northeast-1
  version: "1.31"

iam:
  withOIDC: true

cloudWatch:
  clusterLogging:
    enableTypes:
      - "audit"
      - "authenticator"
      - "controllerManager"
      - "scheduler"

managedNodeGroups:
  - name: ng-1
    nodeRepairConfig:
      enabled: true

autoModeConfig:
  enabled: false

v0.199.0 で自動修復を有効化して作成できるようになっているので、指定しておきます(相変わらず対応が速い!)。
また、ノード監視エージェントアドオンを追加します。

eksctl create addon --name eks-node-monitoring-agent --version 1.0.0 --cluster test-cluster

スクリーンショット 2024-12-28 21.14.04.png

本アドオンは IAM 権限不要でインストールできます。

This add-on doesn’t require additional permissions.
https://docs.aws.amazon.com/eks/latest/userguide/workloads-add-ons-available-eks.html#add-ons-eks-node-monitoring-agent

実際にどのような情報の流れになっているのかはわかりませんが、kubelet 経由等で EC2 のロールを利用して EKS に情報を送る感じでしょうか。

セットアップが完了したので、EKS ノードに障害を模擬してみます。
今回は iptable を修正して、EKS ノード内のコンポーネントが EC2 のロールを利用できなくしてみます。

sudo yum -y install iptables-service
sudo iptables -I OUTPUT 1 -p tcp -d 169.254.169.254 -j DROP
sudo service iptables save
sudo service iptables restart

コマンド実行後、ノードのステータスが NotReady に変わりました。

% kubectl get node
NAME                                                STATUS     ROLES    AGE    VERSION
ip-192-168-57-100.ap-northeast-1.compute.internal   NotReady   <none>   108m   v1.31.3-eks-59bf375
ip-192-168-66-205.ap-northeast-1.compute.internal   Ready      <none>   83m    v1.31.3-eks-59bf375

スクリーンショット 2024-12-28 21.16.02.png

また、iptable に問題を起こしそうなルールが追加されたよ!とノード監視エージェントが検知していました。

スクリーンショット 2024-12-28 22.34.05.png

An unexpected REJECT` or DROP rule was found in the iptables, potentially blocking expected traffic.
https://docs.aws.amazon.com/eks/latest/userguide/node-health.html

かなり細かくノード異常の原因を検知してくれるので、トラブルシューティングが捗りますね。
とはいえ、今回は自動修復を試してみたいので 30 分放っておきます。
30 分強経過した所で、 TerminateInstanceInAutoScalingGroup がコールされて、EKS ノードが自動で再作成されました!

スクリーンショット 2024-12-28 23.11.13.png

ノードの状態も Ready になってますね。

スクリーンショット 2024-12-28 23.08.03.png

TerminateInstanceInAutoScalingGroup の詳細を CloudTrail で確認すると下記内容でした。
ノード監視エージェントや kubelet からの情報を元に EKS がサービスロール経由で自動修復を行ってました。

{
    "eventVersion": "1.08",
    "userIdentity": {
        "type": "AssumedRole",
        "principalId": "AROAR5DGWODCNOJPW6PDC:EKS",
        "arn": "arn:aws:sts::xxxxxxxxxxxx:assumed-role/AWSServiceRoleForAmazonEKSNodegroup/EKS",
        "accountId": "xxxxxxxxxxxx",
        "accessKeyId": "xxxxxxxxxxxx",
        "sessionContext": {
            "sessionIssuer": {
                "type": "Role",
                "principalId": "xxxxxxxxxxxx",
                "arn": "arn:aws:iam::xxxxxxxxxxxx:role/aws-service-role/eks-nodegroup.amazonaws.com/AWSServiceRoleForAmazonEKSNodegroup",
                "accountId": "xxxxxxxxxxxx",
                "userName": "AWSServiceRoleForAmazonEKSNodegroup"
            },
            "webIdFederationData": {},
            "attributes": {
                "creationDate": "2024-12-28T14:06:13Z",
                "mfaAuthenticated": "false"
            }
        },
        "invokedBy": "eks-nodegroup.amazonaws.com"
    },
    "eventTime": "2024-12-28T14:06:13Z",
    "eventSource": "autoscaling.amazonaws.com",
    "eventName": "TerminateInstanceInAutoScalingGroup",
    "awsRegion": "ap-northeast-1",
    "sourceIPAddress": "eks-nodegroup.amazonaws.com",
    "userAgent": "eks-nodegroup.amazonaws.com",
    "requestParameters": {
        "instanceId": "i-0ab76e62066c9730c",
        "shouldDecrementDesiredCapacity": false
    },
    "responseElements": {
        "activity": {
            "activityId": "67365036-5b2d-8de5-5b3d-fd971340ead8",
            "autoScalingGroupName": "eks-ng-1-86ca0689-78c9-a180-dc93-a98a44d722f9",
            "description": "Terminating EC2 instance: i-0ab76e62066c9730c",
            "cause": "At 2024-12-28T14:06:13Z instance i-0ab76e62066c9730c was taken out of service in response to a user request.",
            "startTime": "Dec 28, 2024, 2:06:13 PM",
            "statusCode": "InProgress",
            "progress": 0,
            "details": "{\"Subnet ID\":\"subnet-01ebf5952252d7977\",\"Availability Zone\":\"ap-northeast-1d\"}"
        }
    },
    "requestID": "e9d58984-4b88-4f0e-8796-59b45d1a493c",
    "eventID": "af848fef-390b-497f-9cc6-5305bc6fb6d1",
    "readOnly": false,
    "eventType": "AwsApiCall",
    "managementEvent": true,
    "recipientAccountId": "xxxxxxxxxxxx",
    "eventCategory": "Management"
}

最後に

EKS の自動修復について試してみました。
ノード監視エージェントも合わせて、有効化しておいて損はない機能に思います。
Auto Mode を利用する場合はあまり意識する必要がないかもしれないですが、裏で動いている仕組みへの理解が深まって嬉しいです!
このブログがどなたかの参考になれば幸いです。

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.